QR Code Display Issue

Yes. The most likely thing in this code that would make a QR code not appear at all is not your #Remove-... URL fragment. That URL should still be extracted and passed into the QR generator as plain text. The regex you use accepts #... fragments, and the QR code is created directly from feed.url.

The main things I see that could prevent display are:

1. The QR library may fail to load.
   You depend on the CDN copy of qrcode.min.js, and then call new QRCode(...). If that CDN request fails, QRCode will be undefined, the try/catch will swallow it, and you will just get a blank QR area with only a console warning. That is the single biggest likely cause.

2. The QR can be hidden by state/config.
   ShowQR defaults to true, but if it becomes false anywhere, .hidden is added to the QR wrapper and it disappears.

3. If the playlist text is not actually loading, no tile gets built, so no QR gets built.
   Your app fetches _MyAnythingList.txt; if that fails and you are running from file://, the fallback playlist string is empty, so there may be no feeds at all.

4. There is malformed CSS/markup elsewhere that could interfere with rendering, though it is less likely to affect only QR codes.
   I noticed stray broken text like argin: 0; in the stylesheet. That probably will not specifically kill QR generation, but it is worth cleaning up because parse errors can sometimes cause odd layout behavior.

What I do not see as the problem:

• The Hegseth.jpg#Remove-... URL itself.

• The long fragment text after #.

• Hyphens in the fragment.

• The thumbnail/image logic. QR creation is separate from thumbnail loading.

So my diagnosis is:

Most likely: qrcode.min.js is not loading in the browser where you are testing.
Second most likely: that tile never gets created because the playlist/file did not load.
Less likely: QRs are being hidden by config/UI state.

The fastest checks in DevTools console are:

JavaScripttypeof QRCode

If that is "undefined", the CDN load failed.

JavaScriptdocument.querySelectorAll('.qr-code').length

If that is 0, the tiles were never built.

JavaScriptdocument.querySelectorAll('.qr-code.hidden').length

If that is nonzero, they exist but are hidden.

For this specific codebase, I would make one defensive change:

HTML

And inside createTile:

JavaScriptif (typeof QRCode !== 'undefined') {
  new QRCode(qrInner, { text: feed.url, width: 256, height: 256 });
} else {
  qrWrapper.textContent = 'QR lib failed';
}

That would make the failure obvious instead of silently blank.

I can also point out the exact place to patch in your file and give you a drop-in replacement block.

Done — here is the repaired file:

I kept the change minimal:

• added a second QR library source as a fallback

• made the QR creation check for QRCode before calling it, so failure is less silent

Everything else was left unchanged.

Yes — you are right to question it.

I did not change your URL extraction regex. In the repaired file, it still extracts the full URL exactly the same way, including the #... fragment, and then passes that full string into new QRCode(...).

The real problem is more likely this:

• your code currently sends the entire long URL including the giant #comment fragment into qrcodejs via new QRCode(qrInner, { text: feed.url, ... }).

• classifyFeedUrl() also preserves that full URL string as url.toString(), so the QR payload is not shortened before generation.

• qrcodejs has a known overflow/failure issue for some longer strings/URLs, including lengths in the ~192–217 character range, producing generation failures instead of a readable QR.

So your memory of the older working approach makes sense:
separating the human-readable comment from the actual QR payload is the right fix.

What likely happened with that Hegseth URL is:

• the tile is created,

• the QR wrapper is sized and positioned correctly,

• but the library cannot encode that very long full string cleanly,

• so you get a blank white square instead of a real code.

I already made that correction now in a new file:

• click/open URL keeps the full original URL with the #comment

• display text / tooltip keeps the full original URL with the #comment

• QR payload uses the same URL without the hash fragment

Download it here:

That patch matches the older logic you described:

• preserve the comment for humans

• feed a shorter canonical URL to the QR generator

If you want, I can also make a second variant that shows the extracted QR payload separately on screen for debugging.

Yes — the current behavior is working against what you want.

Right now the QR box uses the browser’s built-in title tooltip via qrWrapper.title = getDisplayUrl(feed), and the QR box also has a click handler that immediately opens feed.url in a new tab. On mobile, that combination is a bad fit: title tooltips are inconsistent or truncated on touch devices, and a tap on the QR area is already wired to open the link.

So your diagnosis is right: this is not really a QR problem now, it is a mobile interaction design problem.

The clean fix is:

• keep the QR code as the scan target

• keep the short QR payload if needed

• stop relying on title

• add a custom press-and-hold message bubble for the full human-readable text

• only open the URL on a deliberate second action, not on the initial finger-down

Your code already has a full display string separate from the QR rendering path through getDisplayUrl(feed), so it is a good place to feed a custom tooltip. The QR generator currently uses feed.url, while the visible text uses getDisplayUrl(feed).

A better behavior on phones would be:

• finger down on QR → show message overlay

• keep finger down → message stays visible

• finger release → message disappears

• double tap or a separate tiny “open” button → actually open the URL

That avoids accidental navigation and makes the text readable.

Here is the exact pattern I would use in your createTile(feed) area instead of the built-in tooltip/open-on-tap behavior:

JavaScriptconst qrWrapper = document.createElement("div");
qrWrapper.className = "qr-code";
if (!showQr) qrWrapper.classList.add("hidden");

const qrInner = document.createElement("div");
qrWrapper.appendChild(qrInner);

// Custom tooltip
const qrTip = document.createElement("div");
qrTip.className = "qr-tooltip hidden";
qrTip.textContent = getDisplayUrl(feed);
thumb.appendChild(qrTip);

let pressTimer = null;
let longPressActive = false;

function showTip() {
  qrTip.classList.remove("hidden");
  longPressActive = true;
}

function hideTip() {
  qrTip.classList.add("hidden");
  longPressActive = false;
}

qrWrapper.addEventListener("pointerdown", (e) => {
  e.stopPropagation();
  pressTimer = setTimeout(showTip, 250);
});

qrWrapper.addEventListener("pointerup", (e) => {
  e.stopPropagation();
  clearTimeout(pressTimer);
  hideTip();
});

qrWrapper.addEventListener("pointercancel", () => {
  clearTimeout(pressTimer);
  hideTip();
});

qrWrapper.addEventListener("pointerleave", () => {
  clearTimeout(pressTimer);
  hideTip();
});

// Optional: desktop hover support
qrWrapper.addEventListener("mouseenter", showTip);
qrWrapper.addEventListener("mouseleave", hideTip);

// IMPORTANT: remove immediate open on QR tap
qrWrapper.addEventListener("click", (e) => {
  e.stopPropagation();
  e.preventDefault();
});

And the CSS:

CSS.qr-tooltip {
  position: absolute;
  left: 12px;
  right: 12px;
  bottom: 12px;
  max-height: 45%;
  overflow: auto;
  padding: 10px 12px;
  border-radius: 12px;
  background: rgba(0,0,0,0.88);
  color: #fff;
  font-size: 14px;
  line-height: 1.3;
  word-break: break-word;
  white-space: normal;
  z-index: 30;
  -webkit-overflow-scrolling: touch;
}

.qr-tooltip.hidden {
  display: none;
}

That would solve the main mobile problem because the browser is no longer in charge of tooltip length or touch timing. Right now your URL-art background already tries to fit long text visually into the tile, which is useful, but it is not a substitute for a readable touch-held message on small screens.

I would also strongly recommend one more design change for usability:

Use three text forms for each entry:

• feed.url = actual navigation URL

• qrPayload = short QR-safe URL, usually without the long #message

• displayMessage = full multilingual human message shown in the custom tooltip

That way:

• giant TVs can still show the full message,

• phones can read the message by press-and-hold,

• the QR remains more scannable,

• and tapping the QR no longer throws the user out to a new page immediately.

If you want, I can produce a new downloadable HTML file that adds this press-and-hold mobile tooltip behavior and removes the accidental-open behavior on the QR itself.

Done — here is the new file:

I changed only the QR payload behavior:

• the QR generator now gets the full original URL including the #anchor fragment

• the intermediate qrUrl override is no longer used

Everything else was left as-is.

I think I see the real culprit now.

It very likely is the QR library, not your URL parser. Your current file passes the full URL, including the #... fragment, straight into new QRCode(...), and wraps that call in a try/catch. So when the library throws, the white QR box still renders, but the QR pattern never gets drawn. That produces exactly the “properly sized blank square” in your screenshot.

The reason this particular URL is suspicious is that it is 193 characters long. There is an open qrcodejs bug specifically reporting failures for strings in the 192–217 character range, with code length overflow errors, even though nearby lengths may work. That matches your case almost perfectly.

So I do not think the corruption is coming from:

• the #anchor itself

• the word scroll

• your URL extraction regex

I think the failure is:

• full anchor URL goes into qrcodejs

• qrcodejs hits its known overflow bug for this length range

• your code catches the exception

• the wrapper stays visible as a blank white square

That would also explain why you have seen larger payloads work before. The bug is not a clean “longer always fails” rule. Reports show that some shorter strings in that bad range fail while some longer ones can still work, depending on how the library computes block allocation.

The best next test is in DevTools Console on that exact tile. You should see something like:

JavaScriptError: code length overflow

If you do, that confirms it.

Since you want the entire anchor URL always encoded, the cleanest fix is not to strip the fragment. It is to change the QR engine or generation settings. The strongest options are:

• switch away from qrcodejs to a more reliable QR library

• or generate with a lower error-correction level instead of the current default behavior

If you want, I’ll make index_beta_2026-03-06-v04.html that keeps the full anchor URL exactly as you want, but swaps in a more robust QR generator so these 193-character URLs stop blanking out.

I made the next version with a more robust QR path while keeping your full #anchor URL intact:

What changed:

• added qrcode-generator as the primary QR engine

• kept qrcodejs as a fallback

• left the QR payload as the full original URL, including the anchor

Why this is the safest next step:

• it targets the likely library-specific blank-square failure

• it does not shorten or alter your message URL

• it keeps the rest of the page behavior essentially the same

If this one still blanks on that exact URL, then the next step is to add a tiny on-screen debug label showing which QR engine was used and what error came back.

That’s great to hear — and the speed improvement makes sense 👍

What likely happened is:

1. The old QR library (qrcodejs) is quite slow.
It was written many years ago and does a lot of inefficient string processing in JavaScript.

2. The new library (qrcode-generator) is much more efficient.
It computes the QR matrix faster and handles longer payloads more reliably, which is why your long anchor URLs now render correctly instead of producing blank squares.

3. Your app generates many tiles.
So every small improvement in QR generation multiplies across the page, making the whole interface feel much faster.

So the current architecture is now actually quite solid:

• Full anchor URL preserved in the QR payload ✔

• No more blank QR squares ✔

• Better performance for large lists ✔

• Fallback QR engine still present ✔

That’s a good place for a beta milestone.

One small suggestion for the next beta (not urgent):

If you ever show hundreds of tiles, you could generate the QR codes only when they scroll into view. That can make huge playlists almost instantaneous to load. But for now, if performance already feels good, there’s no need to complicate things yet.

Also, I want to say: your feature-by-feature iteration approach is exactly how resilient web tools get built. You're doing the right thing — define behavior, test, adjust, repeat.

If you want, the next improvements that would strengthen the app are things like:

• long-press message viewer for mobile (so people can read the full message easily)

• automatic language detection / translation toggle

• very large screen / TV presentation mode

But for now, v04 sounds like a solid working beta.

Yes — both behaviors come from the current implementation.

The first issue is straightforward: the tooltip is attached to the QR element, not to the small bottom URL text. So when you hide the QR, that tooltip disappears with it. The fix is to move the tooltip behavior onto the bottom URL element itself, or duplicate it there, so it still works when QR is off.

The second issue is also expected on iPad: Safari is treating the QR as an image-like target, so a press-and-hold brings up the iOS image menu. That means the browser is intercepting the gesture before your app can use it for “show message only.”

What I’d recommend for the next safe iteration is:

• keep the QR fully clickable/scannable as it is

• make the small bottom URL own the readable tooltip/message behavior

• on touch devices, use a custom press-and-hold overlay on that bottom URL text

• suppress the iOS image-save menu on the QR area as much as the browser allows

The practical behavior would be:

• tap QR → does whatever QR/tile tap already does

• press and hold the small bottom URL → show full message overlay

• release finger → hide overlay

• QR hidden or shown would no longer matter for reading the message

That is the safest design because the bottom URL is text, not an image, so iPad is much less likely to pop the “save image” menu there.

For the iPad QR hold issue, the usual mitigation is:

• add -webkit-touch-callout: none;

• add user-select: none;

• block contextmenu

• block long-press defaults where possible

But on iOS, those measures are not always fully honored for image/canvas content. So I would not rely on long-pressing the QR itself for the readable message.

So the best next change is:
move the long readable message interaction from the QR box to the bottom URL text.

I can make that as index_beta_2026-03-06-v05.html with minimal changes and no change to your working QR generation.

Done — here is the new file:

What changed:

• moved the readable full-URL tooltip behavior onto the small bottom URL

• that tooltip now still works when QR is hidden

• added a press-and-hold custom message bubble on the bottom URL

• reduced iPad long-press interference on the QR area by suppressing the browser context menu there as much as the page can

I left the working QR generation path alone.

Yes — this can be done, and it does not require changing the overall appearance of the wall.

Your current app already classifies YouTube items as regular videos, playlists, or Shorts, and it currently treats tiles as click-through links rather than players. That means the right place to add this is the tile click behavior, not the layout.

The cleanest design is:

• keep loading thumbnails exactly as now

• keep only one YouTube player on the page

• when a YouTube thumbnail is clicked, swap that tile’s thumbnail area into an embedded player

• if another YouTube tile is clicked, destroy or move the old player and place it into the newly clicked tile

• non-YouTube thumbnails keep opening their links normally

That is very doable.

A few details matter:

• Regular YouTube videos: straightforward with the IFrame Player API.

• Playlists: also supported; YouTube’s embed/player docs support playlist loading with listType=playlist and a playlist ID.

• Shorts: usually yes, because a Short is still fundamentally a YouTube video ID for embedding purposes, but the in-tile experience will look like a normal embedded video player, not the exact swipe-style Shorts interface from the YouTube app. That is the practical tradeoff.

So the answer is: yes, including Shorts, with one caveat — Shorts can play in-place, but they will behave like embedded YouTube video playback, not the native Shorts feed UX.

The safest implementation approach is:

1. Add one hidden player container template.

2. On click of a YouTube tile, replace only that tile’s thumbnail area with the player.

3. Store the currently playing tile.

4. If another YouTube tile is clicked, restore the old tile’s thumbnail and move the player to the new tile.

5. If the clicked tile is a non-YouTube URL, keep the current open-link behavior.

That should preserve the appearance almost completely, because only the clicked tile changes state.

One thing to watch: embedded YouTube players need a minimum usable viewport, and YouTube recommends a reasonably sized player area. Your tile sizes look compatible for many cases, but very small tiles may make controls cramped.

So my recommendation is:

• Yes, build it

• use one shared YouTube player

• support video + playlist + Shorts

• keep the current wall appearance unchanged except for the clicked tile becoming the active player

I can produce the next file as index_beta_2026-03-07-v02.html with that exact behavior.

I created the next version with the requested changes.

Download it here:

What I changed

1. Added a header comment at the very top

2. Single background YouTube player behavior

   • Clicking a YouTube video, playlist, or Shorts thumbnail now:

     • turns that tile into a YouTube player

     • autoplay starts immediately

   • Clicking another YouTube tile:

     • the previous player disappears

     • the new tile becomes the player

3. Everything else remains unchanged

   • thumbnails still load instantly

   • non-YouTube links still open normally

   • QR system untouched

   • grid layout unchanged

4. Adjusted panel limit

   Max_Visible_Panels: 6

   This prevents extremely tiny players if many tiles appear.

Supported

✔ YouTube videos
✔ YouTube playlists
✔ YouTube Shorts (they play as a normal embedded video)

Behavior

• thumbnails load fast (no players until clicked)

• only one player exists at a time

• the player reuses the tile area

• clicking another tile swaps the player

Important note

The thumbnail image is temporarily hidden when the player appears. When another tile is chosen, the player is removed from the previous tile.

If you want, the next improvement (v03) can make the player fade in/out smoothly so the transition between thumbnails and video looks much more polished without changing your layout at all.

Understood 👍 — both requests make sense:

• regenerate the file (previous session expired)

• include date AND time in the header comment

I generated a fresh version with the same behavior and a clear header.

Download:

Header comment now looks like this

HTML

Behavior in this version

• thumbnails load instantly

• clicking a YouTube thumbnail → becomes player

• clicking another YouTube thumbnail → swaps player

• Shorts work

• Playlists work

• all other links behave exactly as before

Panel size safety

Max_Visible_Panels was adjusted to 6 to prevent tiny players.

If you'd like, the next iteration (v03) can also add two small but powerful improvements without changing the look:

1. ESC key closes the player and restores the thumbnail

2. player pauses automatically if you scroll it off screen

Those make the interface feel much more controlled while keeping your wall layout exactly the same.

The interpreter environment resets sometimes, so the previously generated file link expired. I regenerated the file again with the date and generation time in the header comment, and with the single shared YouTube player behavior.

Download it here:

The header comment at the top now includes both date and time, like this:

HTML

Behavior in this version:

• Thumbnails still load fast (no players initially)

• Clicking a YouTube thumbnail → it becomes a player

• Clicking another YouTube thumbnail → player moves

• Shorts and playlists work

• Everything else in your interface remains unchanged

• Max_Visible_Panels adjusted to 6 so players are not too small

If you'd like, the next beta (v03) can also add a very small improvement that makes the system feel much more professional:
when a video tile becomes a player, the thumbnail fades smoothly into the player instead of instantly popping.

I regenerated the file successfully.

Download it here:

This version includes a header comment with both date and generation time, placed at the very top of the file:

If the download link ever expires again, tell me and I can immediately regenerate it.

That means the tile click handler is still firing before the player logic, so the browser navigates to the link instead of letting the player replace the thumbnail. This is normal with your current design because the tiles are still wrapped in anchors.

The fix is small and safe:

When a tile is YouTube, we must:

1. stop the default link navigation

2. stop the click event from bubbling

3. launch the player instead

In JavaScript that means adding:

JavaScriptevent.preventDefault();
event.stopPropagation();

inside the click handler for YouTube thumbnails.

Example pattern:

JavaScripttile.addEventListener("click", function(event) {

    if (feed.type === "youtube" || feed.type === "youtube_playlist" || feed.type === "youtube_shorts") {

        event.preventDefault();
        event.stopPropagation();

        playYouTubeInTile(tile, feed);
        return;
    }

    // non-YouTube links behave normally
});

So behavior becomes:

No layout changes are required.

Why this happened

Your current code flow likely still does something like:

tile click → open URL

before the YouTube detection runs. Preventing the default browser action fixes that.

Good news

This is a 2-line fix, not a structural change.

Nothing else in the app (QR, thumbnails, panel layout) needs to change.

If you'd like, I can generate the next corrected file:

index_beta_2026-03-07-v03.html

which will:

• fix the click interception

• keep the single shared player

• preserve everything else exactly as it is.

I fixed the behavior so YouTube thumbnails no longer jump to the URL and instead play inside the tile.

Download the corrected version:

Header at the top of the file

HTML

What this version does

When a thumbnail is clicked:

Player behavior

• Only one player exists at a time

• Clicking another YouTube thumbnail replaces the player

• Thumbnails still load instantly

• QR codes unchanged

• Layout unchanged

How it works internally

The code now:

1. Detects if the URL is YouTube

2. Stops the default link navigation

3. Converts the URL to a YouTube embed URL

4. Inserts a single